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IESG Note 


Several groups within the IETF and IRTF have discussed the Handle 
System and it relationship to existing systems of identifiers. The 
IESG wishes to point out that these discussions have not resulted in 
IETF consensus on the described Handle System nor on how it might fit 
into the IETF architecture for identifiers. Though there has been 
discussion of handles as a form of URI, specifically as a URN, these 
documents describe an alternate view of how namespaces and 
identifiers might work on the Internet and include characterizations 
of existing systems which may not match the IETF consensus view. 


Abstract 


The Handle System is a general-purpose global name service that 
allows secured name resolution and administration over the public 
Internet. This document provides a detailed description of the 
Handle System namespace, and its data, service, and operation models. 
The namespace definition specifies the handle syntax and its semantic 
structure. The data model defines the data structures used by the 
Handle System protocol and any pre-defined data types for carrying 
out the handle service. The service model provides definitions of 
various Handle System components and explains how they work together 
over the network. Finally, the Handle System operation model 
describes its service operation in terms of messages transmitted 
between client and server, and the client authentication process 
based on the Handle System authentication protocol. 
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1. Introduction 


November 2003 


The Handle System manages handles as globally unique names for 


Internet resources. 


paper by Robert Kahn and Robert Wilensky [22] 
System provides a general-purpose global name service that allows 
handles to be resolved and administrated securely over the public 


Internet. 

categories: 
administration service. 
resolve handles into their values. 
deals with client requests to manage these handles, 


and deleting handles, and updating handle values. 


It was originally conceived and described in a 


The Handle 


The Handle System categorizes its service into two 

the handle resolution service and the handle 

Clients use handle resolution service to 

The handle administration service 
including adding 


The document "Handle System Overview" [1] provides an architectural 


overview of the Handle System, 


and its relationship to other Internet 


services such as DNS [2,3] and LDAP[4]. This document provides a 
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detailed description of the Handle System namespace, its data and 
service model, and its operation model. It assumes that readers are 
familiar with the basic concepts of the Handle System as described in 
the overview document. 


The namespace definition specifies the handle syntax and its semantic 
structure. The data model defines the data structures used by the 
Handle System protocol and any pre-defined data types for carrying 
out the handle service. The service model provides definitions of 
various Handle System components and explains how they work together 
over the network. Finally, the Handle System operation model 
describes its service operation in terms of messages transmitted 
between client and server, and the client authentication process 
based on the Handle System authentication protocol. 


2. Handle System Namespace 


Handles are character strings that may consist of a wide range of 
characters. Every handle in the Handle System consists of two parts: 
its naming authority, followed by a unique local name under the 
naming authority. The naming authority and the local name are 
separated by the ASCII character "/" (octet 0x2F). The following 
table provides the handle syntax definition in ABNF [5] notation: 


<Handle> = <NamingAuthority> "/" <LocalName> 
<NamingAuthority> = *(<NamingAuthority> ".") <NAsegment> 
<NAsegment> = 1*(%x00-2D / %x30-3F / %x41-FF ) 


; any octets that map to UTF-8 encoded 

; Unicode 2.0 characters except 

; octets ’0x2E’ and ’0x2F’ (which 

; correspond to the ASCII characters ’.’, 
; and //’). 


<LocalName> = * (%x00-FF) 
; any octets that map to UTF-8 encoded 
; Unicode 2.0 characters 


Table 2.1: Handle syntax 


As shown in Table 2.1, both <NamingAuthority> and <LocalName> are 
UTF-8 [6] encoded character strings. The Handle System protocol 


mandates UTF-8 encoding for handles transferred over the wire. The 
<LocalName> may consist of any characters from the Unicode 2.0 
standard [7]. The <NamingAuthority> may use any characters from the 


Unicode 2.0 standard except the ASCII character ’'/’ (0x2F), which is 
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reserved to separate the <NamingAuthority> from the <LocalName>. A 
<NamingAuthority> may consist of multiple non-empty <NAsegment>s, 
each of which separated by the ASCII character ’.’ (octet Ox2E). 


Naming authorities are defined in a hierarchical fashion resembling a 
tree structure. Each node and leaf of the tree is given a label that 
corresponds to a naming authority segment (<NAsegment>). The parent 
node represents the parent naming authority. Naming authorities are 
constructed left to right, concatenating the labels from the root of 
the tree to the node that represents the naming authority. Each 
label (or its <NAsegment>) is separated by the character ’.’ (octet 
Ox2E). For example, the naming authority for the Digital Object 
Identifier (DOI) project is "10". It is a root-level naming 
authority as it has no parent naming authority for itself. It can, 
however, have many child naming authorities. For example, "10.1045" 
is a child naming authority of "10" for the D-Lib Magazine. 


By default, handles are case sensitive. However, a handle service, 
global or local, may implement its namespace so that ASCII characters 
under the namespace are treated as case insensitive. For example, 
the global handle service, formally known as the Global Handle 
Registry (GHR), is implemented such that ASCII characters are treated 
as case insensitive. Since the GHR manages all handles for naming 
authorities, ASCII characters in naming authorities are treated as 
case insensitive. 


3. Handle System Data Model 


The Handle System provides a name-to-value binding service over the 
public Internet. Each handle may have a set of values assigned to 
it. The Handle System maintains the value set of each handle and 
will return it in response to any handle resolution request. The 
Handle System data model defines the conceptual data structure for 
these values. The data model used by the protocol may not be the 
exact physical data model used for storage in any specific 
implementation. Rather, it is the data model followed by the Handle 
System protocol as specified in the "Handle System Protocol 
Specification" [8]. 


3.1. Handle Value Set 


Each handle may have a set of values assigned to it. These handle 
values use a common data structure for its data. For example, each 
handle value has a unique index number that distinguishes it from 
other values in the value set. It also has a specific data type that 
defines the syntax and semantics of the data in its data field. 
Besides these, each handle value contains a set of administrative 
information such as TTL and permissions. Figure 3.1 shows the handle 
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"10.1045/may99-payette" with a set of three handle values. One of 
these values (with index number set to 1) is shown in detail. (Note 
that the encoding of the length for each field is not shown in Figure 
3.1. Also, the empty <reference> field consists of a 4-byte integer 
whose value is zero.) 


Handle "10.1045/may99-payette" 


V 
| <index>: 3 | 

EA E EE E E ES E E a i E E E E E E E | 

| <index>: 2 | | 
| | | | 
| <index>: 1 | | | 
| <type>: URL eae 
| <data>: http://www.dlib.org/dlib... | | 

<TTL>: {Relative: 24 hours} 

<permission>: PUBLIC_READ, ADMIN_WRITE 
| <timestamp>: 927314334000 a a 
| <reference>: {empty} | |- 


Figure 3.1: Handle "10.1045/may99-payette" and its set of values 


In Figure 3.1, it shows a handle value whose its index is set to 1. 
The data type for the handle value is URL. The URL data as stated in 
the <data> field is "http://www.dlib.org/dlib...". The TTL (time to 
live) entry suggests that the value record should be cached no more 
than 24 hours before the source of the information to be consulted 
again. The <permission> field grants anyone permission to read, but 
only the administrator to update the value. The <reference> field is 
empty. It may contain a list of references to other handle values as 
credentials for this handle value. 


Thus a handle value may be thought of as a record that consists of a 
group of data fields. Each of these data fields is defined as 
follows: 


<index> 


An unsigned 32-bit integer that uniquely identifies a handle value 
from other handle values. 
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<type> 

A UTF8-string that identifies the data type for the value record. 
Note that throughout this document, a UTF8-string is defined as a 
data structure that consists of a 4-byte unsigned integer followed 
by an UTF-8 encoded character string. The integer specifies the 
number of octets in the character string. 


The <type> field identifies the data type that defines the syntax 
and semantics of data in the next <data> field. The data type may 
be registered with the Handle System to avoid potential conflicts. 
The Handle System has a reserved naming authority "0.TYPE" for 
registered data types. For example, "URL" (as shown in Figure 
3.1) is a registered data type. It is registered as the handle 
"0.TYPE/URL". The handle may have a value that explains the 
syntax and semantics of the data type. 


Data types under the Handle System may be hierarchical. Each 
level of the hierarchy may be named in terms of a UTF8-String with 
no ’.’ (Qx2E) characters. The ’.’ character is used to mark the 
boundary between hierarchy levels. For example, the Handle System 
data type "a.b" may be considered as a sub-type "b" under the type 
"a". Similarly, handle values of <type> "a.b.x", "a.b.y" and 
"a.b.z" may be considered as handle values under the common type 
hierarchy "a.b". 


For any handle values, the UTF8-string in the <type> field may not 
end with the ’.’ character. In other words, no Handle System data 
type should end with the ’.’ character. However, the ’.’ 
character may appear in the end of the <type> parameter ina 
handle query. This is used to query for all handle values under a 
common type hierarchy. For example, one may query for all handle 
values under the type hierarchy "a.b" (e.g., handle values of 
<type> "a.b.x", "a.b.y" and "a.b.z") by setting the <type> 
parameter to "a.b.". Note here that the <type> parameter ends 
with the ’.’ character. Details of the handle query operation can 
be found in the Handle System protocol specification [8]. 


<data> 
A sequence of octets (preceded by its length in a 4-byte unsigned 
integer) that describes the resource identified by the handle. The 
syntax and semantics of these octets are identified by the <type> 
field. 


<permission> 
An eight-bit bit-mask for access control of the handle value. 
Access control is defined in terms of read, write, and execute 


Sun, et al. Informational [Page 6] 


RFC 3651 Handle System Service Definition November 2003 


permissions, applicable to either general public or handle 
administrator(s). Each handle value can have its permission field 
specified as any combination of the following bits: 


PUBLIC_WRITE (0x01) 
PUBLIC_READ (0x02) 
ADMIN_WRITE (0x04) 
ADMIN_READ (0x08) _ 


PUBLIC_EXECUTE (0x10) 


ADMIN_EXECUTE (0x20) 


permission that allows anyone to 
modify or delete the handle value. 


permission that allows anyone to read 
the handle value. 


permission that allows any handle 
administrator to update or delete the 
handle value. 


permission that allows the handle 
value to be read by any handle 
administrator with AUTHORITIVE_READ 
privilege. 


permission that allows anyone to 
execute the program identified by the 
handle value on the handle host as 
anonymous user. Because of the 
security risks this may have brought 
up, implementations may choose not to 
support such permission, or provide 
options so that it can be disabled at 
deployment. 


permission that allows handle 
administrator(s) to run the program 
identified by the handle value on the 
handle server. The handle server must 
authenticate the handle administrator 
before executing the program. The 
handle administrator must have an 
established account on the handle 
server. The execution of the handle 
value should assume the same privilege 
as the one given to the account for 
the handle administrator. Because of 
the security risks this may have 
brought up, implementations may choose 
not to support such permission, or 
provide options so that it can be 
disabled at deployment. 
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Note that a handle value with no PUBLIC_READ nor ADMIN_READ 
permission can not leave the handle server. It may be used, for 
example, to store secret keys for authentication purposes. A 
handle value with neither PUBLIC_WRITE nor ADMIN_WRITE permission 
makes the handle value immutable and cannot be deleted by any 
handle administrator (via the Handle System protocol). 


The administrator for a given handle must specify the permission 
for each handle value. Implementations may choose PUBLIC_READ and 
ADMIN_WRITE as the default permission for each handle value. 
Handle servers must check permissions before fulfilling any client 


request. 

<TTL> 

An octet followed by a 4-byte integer that specifies the Time-To- 
Live of the value record. It is used to describe how long the 


value record can be cached before the source of the information 
should again be consulted. A zero value for a TTL indicates that 
the value record should only be used for the transaction in 
progress and should not be cached. Any non-zero TTL is defined in 
terms of a TTL type (specified in the first octet), followed by 
the TTL value (the 32-bit unsigned integer that follows the TTL 
type). The TTL type indicates whether the TTL value is absolute 
or relative. The absolute TTL value defines the time to live in 
terms of seconds since 00:00:00 UTC, January 1st 1970. A relative 
TTL specifies the time to live in terms of the number of seconds 
elapsed since the value was obtained by the client from any handle 
server. 


<timestamp> 

An 8-byte (long) integer that records the last time the value was 
updated at the server. The field contains elapsed time since 
00:00:00 UTC, January 1970 in milliseconds. The choice of 
milliseconds is to avoid potential collision when updating the 
value. 


<reference> 

A 4-byte integer followed by a list of references to other handle 
values. The integer specifies the number of references in the 
list. Each reference in the list refers to another handle value 
in terms of a UTF8-string and a 4-byte integer (where the UTF8- 
string is the handle name and the integer is the value index). 
References are generally used to add credentials to the current 
handle value. For example, a handle value may make itself more 
trust-worthy by referring to a digital signature issued by a 
commonly trusted entity. 
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By default, the Handle System returns all the handle values with 
public-read permission in response of any resolution request. It is 
possible for a client to ask for a subset of those values with 
specific data type (e.g., all URLS assigned to the handle). The 
client may also ask for a specific handle value based on a specific 
value index. 


Each handle value can be uniquely referenced by the combination of 
the handle and its value index. Care must be taken when changing the 
value index as it may break an existing reference to the handle 
value. For example, suppose the handle X/Y has a value whose index 
is 1. That value may be referred to as X/Y:1. If the handle 
administrator changes the value index from 1 to 2, the reference to 
X/Y:1 will become obsolete. Any reference to the handle value will 
have to change to X/Y:2. 


Value records assigned to any handle may or may not have continuous 
index numbers. Nor can it be assumed that the index will start with 
O or 1. A handle administrator may assign a handle value with any 
index as long as each index is unique within the value set. 


A handle value may be "privatized" or "disabled" by setting its 
<permission> field as "authorized-read". This limits read-access to 
the handle administrator only. The "privatized" value can then be 
used to keep any historical data (on behalf of the handle 
administrator) without exposing it to public. Such approach may also 
be used to keep any obsolete handle or naming authority from being 
reused accidentally. 


3.2. Pre-defined Handle Data Types 


Every handle value must have a data type specified in its <type> 
field. The Handle System provides a type registration service that 
allows organizations to register new data types for their 
applications. Data types can be registered as handles under the 
naming authority "O.TYPE". For example, the URL data type is 
registered under the Handle System as the handle "0.TYPE/URL". The 
handle may have a handle value that refers to RFC1738 [9], an IETF 
standard document that defines the syntax and semantics of URL. 


The Handle System pre-defines a set of data types to carry out the 
handle service. For example, HS_ADMIN is a pre-defined data type 
used to describe handle administrators or administrator groups. 

HS_ SITE is a pre-defined data type to describe the service interface 
of any Handle System service component. The following sections 
provide detailed descriptions of these pre-defined data types under 
the Handle System. 
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3.2.1. Handle Administrator: HS_ADMIN 


Each handle has one or more administrators. Any administrative 
operation (e.g., add, delete or modify handle values) can only be 
performed by the handle administrator with adequate privilege. 

Handle administrators are defined in terms of HS_ADMIN values. Every 
handle must have at least one HS_ ADMIN value that defines its 
administrator. Each HS_ADMIN value can be used to define a set of 
handle administrators sharing the same administration privilege. 
Handles with multiple administrators of different privileges may have 
multiple HS_ADMIN values. HS_ADMIN values are used by the Handle 
System to authenticate handle administrators before fulfilling any 
handle administration request. 


Naming authorities, as described above, are themselves registered as 
handles under the reserved naming authority "0.NA". These handles 
are referred to as naming authority handles. Administrators for any 
naming authority are defined as the administrators of the 
corresponding naming authority handle. For example, "0.NA/10" is the 


naming authority handle for the naming authority "10". Hence any 
administrator for the naming authority handle "0.NA/10" is also the 
administrator for the naming authority "10". Naming authority 


administrators are the only ones who can create handles or sub- 
naming authorities under the naming authority. A sub-naming 
authority may define its own set of administrators to create handles 
or further levels of sub-naming authorities. For example, the naming 
authority "10.1045" may have a totally different group of 
administrators from its parent naming authority "10". 


An HS_ADMIN value is a handle value whose <type> field is HS_ADMIN 
and whose <data> field consists of the following entries: 


<AdminRef> 

A reference to a handle value. The reference consists of the 
handle name (a UTF8-string) followed by a 4-byte unsigned integer 
for the handle value index. The handle value identifies the set 
of administrators for the handle. 


<AdminPermission> 
A 16-bit bit-mask that defines the administration privilege of the 
set of handle administrators identified by the HS_ADMIN value. 


The <AdminRef> entry refers to a handle value that can be used to 
authenticate the handle administrator. Such handle value is called 
the handle administrator reference. The handle administrator 
reference may contain the secret key, public key, or X.509 
certificate [10] provided by the handle administrator. For example, 
the <AdminRef> entry may contain a handle administrator reference 
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whose <type> field is DSS_WITH_DES_CBC_SHA and whose <data> field 
contains a DES secret key [11], for use in the Cipher Block Chaining 
(CBC) mode of operation [12, 13]. The secret key can be used by the 
handle server to authenticate the handle administrator. For stronger 
cryptographic algorithm, the handle administrator reference may 
contain a set of Triple-DES keys [23] and set its <type> to be DES- 
EDE3-WITH-CBC. 


A single handle may be assigned with both the HS_ADMIN value and the 
handle administrator reference. In other words, the <AdminRef> entry 
may refer to a handle value assigned to the same handle that has the 
HS_ADMIN value. In this case, authentication of the handle 
administrator does not rely on any other handles. Alternatively, the 
handle administrator reference may be a handle value under a 
different handle. Thus HS_ADMIN values from different handles may 
share a common handle administrator reference. This feature allows 
sharing of handle administrators among different handles. The handle 
administrator reference contains the secret key, public key, or X.509 
certificate provided by the administrator of these handles. 


Handle administrator reference may be of type HS_VLIST and has its 
<data> field contain a list of references to other handle values. 
Each of these handle values defines a handle administrator reference. 
The HS_VLIST value defines an administrator group. Each handle 
administrator reference from the HS_VLIST is a member of the 
administrator group. Each handle value reference is defined in terms 
of a <handle>:<index> pair. An administrator group may also contain 
other administrator groups as its members. This allows administrator 
groups to be defined in a hierarchical fashion. Care must be taken, 
however, to avoid cyclic definition of administrators or 
administrator groups. Multiple levels of administrator groups should 
be avoided due to their lack of efficiency, but will not be signaled 
as an error. Client software should be prepared to detect any 
potential cyclic definition of administrators or <AdminRef> entries 
that point to non-existent handle values and treat them as an error. 


A handle can have multiple HS_ADMIN values, each of which defines a 
different handle administrator. Different administrators can play 
different roles or be granted different permissions. For example, 
the naming authority handle "0.NA/10" may have two administrators, 
one of which may only have permission to create new handles under the 
naming authority, while the other may have permission to create new 
sub-naming authorities (e.g., "10.1045"). The set of possible 
permissions for a handle administrator is defined as follows: 


Add_Handle (0x0001) 


This permission allows naming authority administrator to create new 
handles under a given naming authority. 
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Sun, 


Delete_Handle (0x0002) 
This permission allows naming authority administrator to delete 
handles under a given naming authority. 


Add_NA (0x0004) 
This permission allows the naming authority administrator to create 
new sub-naming authorities. 


Delete_NA (0x0008) 
This permission allows naming authority administrator to delete an 
existing sub-naming authority. 


Modify Value (0x0010) 

This permission allows handle administrator to modify any handle 
values other than HS_ADMIN values. HS_ADMIN values are used to 
define handle administrators and are managed by a different set of 
permissions. 


Delete_Value (0x0020) 
This permission allows handle administrator to delete any handle 
value other than the HS_ADMIN values. 


Add_Value (0x0040) 
This permission allows handle administrator to add handle values 
other than the HS_ADMIN values. 


Modify _Admin (0x0080) 
This permission allows handle administrator to modify HS_ADMIN 
values. 


Remove_Admin (0x0100) 
This permission allows handle administrator to remove HS_ADMIN 
values. 


Add_Admin (0x0200) 
This permission allows handle administrator to add new HS_ADMIN 
values. 


Authorized_Read (0x0400) 

This permission grants handle administrator read-access to handle 
values with the ADMIN_READ permission. Administrators without this 
permission will not have access to handle values that require 
authentication for read access. 


LIST_Handle (0x0800) 


This permission allows naming authority administrator to list 
handles under a given naming authority. 
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LIST_NA (0x1000) 
This permission allows naming authority administrator to list 
immediate sub-naming authorities under a given naming authority. 


Administrator permissions are encoded in the <AdminPermission> entry 
in the <data> field of any HS_ADMIN value. Each permission is 
encoded as a bit flag. The permission is granted if the flag is set 
to 1, otherwise it is set to 0. 


Figure 3.2.1 shows an example of HS_ADMIN value that defines an 


administrator for the naming authority handle "0.NA/10". In figure 
3.2.1, a naming authority administrator is identified by an HS_ADMIN 
value assigned to the naming authority handle "0.NA/10". The 


administrator can be authenticated based on the handle value 
"Q0.NA/10":3, which is the handle value assigned to the naming 
authority handle "0.NA/10" and has its index set to 3. The handle 
value "0.NA/10":3 may contain the secret or public key used by the 
administrator. The administrator is granted permission to add, 
delete, or modify sub-naming authorities under "10", and add or 
delete handles directly under the naming authority. The 
administrator may also add, delete, or modify any handle values 
assigned to the naming authority handle except those HS_ADMIN values. 
In other words, the administrator is not allowed to add, delete, or 
modify any administrators for the naming authority. 


| 
| || | 
| <index>: 2 | | | 
| <type>: HS_ADMIN | | | 
| <data>: | | | 
| <AdminRef>: "0.NA/10": 3 | | | 
| <AdminPerm>: Add_NA, Delete_NA, | | 

Add Handle, Delete_Handle, 

| Add_Value, Delete_Value, Modify_Value, | | | 
| Authorized Read, List_Handle, List _NA | | 
| 
| <TTL>: 24 hours | | 
| <permission>: PUBLIC_READ, ADMIN_WRITE | | | 
| <reference>: {empty } | - 


Figure 3.2.1: Administrator for the naming authority 
handle "0.NA/10" 
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HS_ ADMIN values are used by handle servers to authenticate the handle 
administrator before fulfilling any administrative requests. The 
server authenticates a client by checking whether the client has 
possession of the secret key (or the private key) that matches the 
one in any of the handle administrator references. The 
authentication is carried out via the Handle System authentication 
protocol as described later in this document. 


HS_ADMIN values may require authentication for read access in order 
to prevent public exposure of the data. Additionally, the handle 
administrator reference that contains the administrator’s secret key 
should have neither PUBLIC_READ nor ADMIN_READ permission to prevent 
the key from leaving the server. 


3.2.2. Service Site Information: HS_SITE 


The Handle System consists of a single distributed global handle 
service, also known as the Global Handle Registry (GHR), and 


unlimited number of Local Handle Services (LHSs). Each handle 
service, global or local, may be replicated into multiple service 
sites. Each service site may consist of multiple server computers. 


Service requests targeted at any handle service can be distributed 
into different service sites, and into different server computers 
within any service site. Such architecture assures that each handle 
service could have the capacity to manage any large number of handles 
and handle requests. It also provides ways for each handle service 
to avoid any single point of failure. 


Each handle service, global or local, may provide the same set of 
functions for resolving and administering its collection of handles. 
Handle services differ primarily in that each service is responsible 
for a distinct set of handles. They are also likely to differ in the 
selection, number, and configuration of their components such as the 
servers used to provide handle resolution and administration. 
Different handle services may be created and managed by different 
organizations. Each of them may have their own goals and policies. 


A service site typically consists of a cluster of server computers 
residing within a local Internet domain. These computers work 
together to distribute the data storage and processing load at the 
site. It is possible, although not recommended, to compose a site 
from servers at widely different locations. Further, it is even 
possible to compose two different sites from the same set of servers. 


Each service site is defined by an HS_SITE value. HS_SITE is a 
pre-defined Handle System data type. An HS_SITE value defines a 
service site by identifying the server computers (e.g., IP addresses) 
that comprise the site along with their service configurations (e.g., 
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port numbers). HS_SITE values are typically assigned to naming 
authority handles. The set of HS_SITE values assigned to a naming 
authority handle is called the service information for the naming 
authority. 


The service information is managed by the naming authority 
administrator. It must reflect the configuration of the handle 
service for the naming authority. Note that an additional layer of 
indirection, called a service handle, can be used to allow multiple 
naming authorities to reference a single set of HS_SITE values, as 
described later in this document (see section 3.2.3). Clients of the 
Handle System depend on the service information to locate the 
responsible handle server before they can send their service 
requests. The service information can also be used by clients to 
authenticate any service response from the handle server. 


An HS_SITE value is a handle value whose <type> field is HS_SITE and 
whose <data> field consists of the following entries: 


<Version> 

A 2-byte value that identifies the version number of the HS_SITE. 
The version number identifies the data format used by the HS_SITE 
value. It is defined to allow backward compatibility over time. 
This document defines the HS_SITE with version number 0. 


<ProtocolVersion> 

A 2-byte integer value that identifies the handle protocol version. 
The higher byte of the value identifies the major version and the 
lower byte the minor version. Details of the Handle System 
protocol is specified in [8]. 


<SerialNumber> 

A 2-byte integer value that increases by 1 (and may wrap around 
through 0) each time the HS_SITE value gets changed. It is used in 
the Handle System protocol to synchronize the HS_SITE values 
between client and server. 


<PrimaryMask> 

An 8-bit mask that identifies the primary site(s) of the handle 
service. The first bit of the octet is the <MultiPrimary> bit. It 
indicates whether the handle service has multiple primary sites. 
The second bit of the octet is the <PrimarySite> bit. It indicates 
whether the HS_SITE value is a primary site. A primary site is the 
one that supports administrative operations for its handles. A 
<MultiPrimary> entry with zero value indicates that the handle 
service has a single primary site and all handle administration has 
to be done at that site. A non-zero <MultiPrimary> entry indicates 
that the handle service has multiple primary sites. Each primary 


Sun, et al. Informational [Page 15] 


RFC 3651 Handle System Service Definition November 2003 


site may be used to administrate handles managed under the handle 
service. Handles managed by such service may identify its primary 
sites using an HS_PRIMARY value, as described in section 3.2.5. 


<HashOption> 

An 8-bit octet that identifies the hash option used by the service 
site to distribute handles among its servers. Valid options 
include HASH BY_NA (0x00), HASH _BY_ LOCAL (0x01), or HASH _BY_ HANDLE 
(0x02). These options indicate whether the hash operation should 
only be applied to the naming authority portion of the handle, or 
only the local name portion of the handle, or the entire handle, 
respectively. The standard MD5 hashing algorithm [14] is used by 
each service site to distribute handles among its servers. 


<HashFilter> 
An UTF8-string entry reserved for future use. 


<AttributeList> 

A 4-byte integer followed by a list of UTF8-string pairs. The 
integer indicates the number of UTF8-string pairs that follow. 

Each UTF8-string pair is an <attribute>:<value> pair. They are 
used to add literal explanations of the service site. For example, 
if the <attribute> is "Organization", the <value> should contain a 
description of the organization hosting the service site. Other 
<attribute>s may be defined to help distinguish the service sites 
from each other. 


<NumOfServer> 
A 4-byte integer that defines the number of servers in the service 
site. The entry is followed by a list of <ServerRecord>s. Each 


<ServerRecord> defines a handle server that is part of the service 
site. Each <ServerRecord> consists of the following data fields: 


<ServerRecord> ::= <ServerID> 
<Address> <PublicKeyRecord> <ServiceInterface> 


where each field is defined as follows: 


<ServerID> 

A 4-byte unsigned integer that uniquely identifies a server 
process under the service site. <ServerID>s do not have to 
begin with 1 and they don’t have be consecutive numbers. They 
are used to distinguish servers under a service site from each 
other. Note that there can be multiple servers residing on any 
given computer, each with a different <ServerID>. 
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<Address> 
The 16-byte IPv6 [15, 16] address of the handle server. Any 
IPv4 address should be presented as :::::FFFF:xxxx:xxxx (where 


XXXX:XXXX Can be any 4-byte IPv4 address). 


<PublicKeyRecord> 

A 4-byte integer followed by a byte-array that contains the 
server’s public key. The integer specifies the size of the 
byte-array. The byte-array (for the publickey) consists of 
three parts: a UTF8-string that describes the key type, a 
two-byte option field reserved for future use, and a byte-array 
that contains the public key itself. For example, the UTF8- 
String "DSA_PUB_KEY" indicates that the <PublicKeyRecord> 
contains a DSA public key. The storage format of the DSA key 
in the byte-array could then be found from the handle 
"O.type/DSA_PUB_KEY". Public key in the <PublicKeyRecord> can 
be used to authenticate any service response from the handle 
server. 


The <PublicKeyRecord> may also contain an X.509 certificate. 
This happens if the key type field contains the UTF8-String 
"CERT.X509". In this case, "CERT.X509" will map to the handle 
"0.TYPE/CERT.X509". The handle may contain information that 
describes the syntax and semantics of the public key or its 
certificate. Additional key type may also be registered (as 
handles under "0.TYPE") to further distinguish different kinds 
of X.509 certificates. For example, "CERT.X509.DSA" may be 
used to denote X.509 certificates that contain DSA public keys. 
If the key type field of a <PublicKeyRecord> declares 
"CERT.X509.DSA", the <PublicKeyRecord> must contain a X.509 
certificate with a DSA public key in it." 


<ServiceInterface> ::= <InterfaceCounter> 
* [ <ServiceType> 
<TransmissionProtocol> 
<PortNumber> ] 


A 4-byte integer followed by an array of triplets consisting of 
<ServiceType, TransmissionProtocol, PortNumber>. The 4-byte 
integer specifies the number of triplets. Each triplet lists a 
service interface provided by the handle server. For each 
triplet, the <ServiceType> is an octet (as a bit mask) that 
specifies whether the interface is for handle resolution 
(0x01), handle administration (0x02), or both. The 
<TransmissionProtocol> is also an octet (as a bit mask) that 
specifies the transmission protocol. Possible transmission 
protocols include TCP (0x01), UDP (0x02), and HTTP (0x04). The 


Sun, et al. Informational [Page 17] 


RFC 3651 Handle System Service Definition November 2003 


<PortNumber> is a 4-byte unsigned integer that specifies the 
port number used by the interface. The default port number is 
2641. 


Figure 3.2.2 shows an example of handle service site in terms of a 
HS_ SITE value. The HS_SITE value is assigned to the naming authority 
handle "0.NA/10". The <PrimaryMask> indicates that it is the only 
primary site of the handle service. The site consists of three 
handle servers, as indicated in the <NumOfServer>. These servers 
provide handle resolution and administration service for every handle 
under the naming authority "10". The first server record (ServerID 
0) shows two service interfaces, one for handle resolution and the 
other for handle administration. Each interface has its own port. 


Each server within a service site is responsible for a subset of 
handles managed by the handle service. Clients can find the 
responsible server by performing a common hash-operation. The hash- 
operation will first convert all ASCII characters in the handle into 
upper-case. It then applies the MD5 hashing upon the portion of the 
converted handle string (according to the <HashOption> entry). The 
result is a 16-byte integer. The absolute value of the integer will 
be divided by the number of servers (specified in the <NumOfServer> 
entry). The remainder is the sequence number (starting with zero) of 
the <ServerRecord> listed in the HS_SITE value. From the 
<ServerRecord>, clients can find the IP address of the handle server 
for their handle requests. 
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<index>: 2 
<type>: HS_SITE 
<data>: 
Version: 0 
ProtocolVersion: 2.1 
SerialNumber: J 
PrimaryMask: 
MultiPrimary: FALSE 
PrimarySite: TRUE 
HashOption: HASH _BY_ HANDLE 
HashFilter: {empty UTF8-String} 
AttributeList: 0 {followed by no attributes} 
NumOfServer: 3 


{followed by a list of <ServerRecord>} 


Address: ?:FFFF:132.151.1.155 
PublicKeyRecord: HS_DSAKEY, iQCuR2R... 
ServiceInterface 


| | 
| | 
| | | 
| | 
| ServiceType: Resolution_Only | | 
TransmissionProtocol: TCP & UDP | 

| PortNumber: 2641 
| 
| ServiceType: Admin only | 
| TransmissionProtocol: TCP | | 
| PortNumber: 2642 

<ITL>: 24 hours 

<permission>: PUBLIC_READ, ADMIN_WRITE 

<reference>: {empty } - 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| ServerID: Si | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


Fig. 3.2.2: The primary service site for the naming authority "10" 
3.2.3. Naming Authority Delegation Service: HS_NA_DELEGATE 
The HS_NA_ DELEGATE is a pre-defined Handle System data type. It has 


the exact same format as the HS_SITE value. Like HS_SITE values, 
HS_NA_ DELEGATE values are used to describe service sites of a LHS. 
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HS_ NA DELEGATE values may be assigned to naming authority handles to 
designate naming authority administration to a LHS. A naming 
authority handle with a set of HS_NA_ DELEGATE values indicates that 
all child naming authorities of the naming authority are managed by 
the LHS described by the HS_NA_DELEGATE values. 


For example, suppose the naming authority "foo.bar" decides to have 
its child naming authorities delegated to a LHS. To achieve this, 
one may assign the naming authority handle "0.NA/foo.bar" with a set 
of HS_NA_ DELEGATE values that describes the LHS. The set of 

HS NA DELEGATE values indicate that the service information of any 
child naming authority of the "foo.bar", such as "foo.bar.baz", can 
be found by querying the naming authority handle "0.NA/foo.bar.baz" 
from the LHS. 


3.2.4. Service Handle: HS_SERV 


Any handle service, global or local, can be defined in terms of a set 
of HS_SITE values. These HS_SITE values may be assigned directly to 
the relevant naming authority handle, or an additional level of 
indirection may be introduced through the use of service handles. A 
service handle may be thought of as a name for a handle service. It 
may be used to maintain the HS_SITE values for the handle service and 
referenced from a naming authority handle via a HS_SERV value. A 

HS_ SERV value is a handle value whose <type> field is HS_SERV and 
whose <data> field contains the reference to the service handle. 
HS_SERV values are typically assigned to naming authority handles to 
refer clients to the responsible handle service. 


Use of service handle allows sharing of service information among 
multiple naming authorities. It also allows changes to service 
configuration (e.g., adding a new site) to be made in one place 
rather than in every naming authority handle involved. The mechanism 
may also be used to support service referral from one handle service 
to another for whatever reason. 


A naming authority handle may have no more than one HS_SERV value 
assigned to it, otherwise it is an error. If a naming authority 
handle has both a list of HS_SITE values and an HS_SERV value, the 
HS_ SITE values should be used as the service information for the 
naming authority. 


Service handles can be registered under the reserved naming authority 
"Q0.SERV". Handles under "0.SERV" are managed by the GHR. For 
example, the service handle "0.SERV/123" may be created to maintain 
the service information for the handle service that manages handles 
under the naming authority "123" and any of its sub-naming 
authorities. 
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Similarly, a service handle "0.SERV/a.b.c" may be created to host the 
service information for the handle service that manages handles under 
the naming authority "a.b.c". 


The use of service handles raises several special considerations. 
Multiple levels of service handle redirection should be avoided due 
to their lack of efficiency, but are not signaled as an error. 
Looped reference of service handles or HS_SERV values that point to 
non-existent service handles should be caught and error conditions 
passed back to the user. 


3.2.5. Alias Handle: HS_ALIAS 


In practice, it is very possible that a digital object may have 
multiple names that will identify the object. The Handle System 
supports such feature via the pre-defined data type HS_ALIAS. An 
HS_ ALIAS value is a handle value whose <type> field is HS_ALIAS and 
whose <data> field contains a reference to another handle. A handle 
with a HS_ALIAS value is an alias handle to the handle referenced in 
the HS_ALIAS value. An alias handle should not have any additional 
handle values other than HS_ALIAS or HS_ADMIN (for administration) 
values. This is necessary to prevent any inconsistency between a 
handle and its aliases. 


During a handle resolution, a client may get back an HS_ALIAS value. 
This indicates that the handle in question is an alias handle. The 
client may then retry the query against the handle specified in the 
HS_ALIAS value until final results are obtained. 


The use of alias handle introduces a number of special 
considerations. For example, multiple levels of aliases should be 
avoided for the sake of efficiency, but are not signaled as an error. 
Alias loops and aliases that point to non-existent handles should be 
caught and error conditions passed back to the user. 


One potential use of alias handle would be to support the transfer of 
ownership of any named resource. When a resource identified by a 
handle transfers from one organization to another, a new handle for 
the resource may be created. To avoid inconsistency and any broken 
reference, the handle used before the ownership transfer may be 
changed into an alias handle and point its HS_ALIAS value to the 
newly created handle. 


Bie2 Oe Primary Site: HS PRIMARY 
HS PRIMARY is a pre-defined data type used to designate the primary 


service sites for any given handle. A handle service with multiple 
primary service sites is called a multi-primary service. Otherwise 
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it is called a single-primary service. Each handle managed by a 
multi-primary handle service may specify its primary service sites in 
terms of an HS PRIMARY value. A HS_PRIMARY value is a handle value 
whose <type> field is HS_PRIMARY and whose <data> field contains a 
list of references to HS_SITE values. Each of these HS_SITE defines 
a primary service site for the handle. 


There can be at most one HS_PRIMARY value assigned to each handle. 
Otherwise it is an error. A handle with no HS_PRIMARY value but 
managed by a multi-primary handle service is not an error. In this 
case, every primary service site of the handle service will also be 
the primary site for the handle. Handles managed by a single-primary 
handle service do not need any HS_PRIMARY values and any such values 
should be ignored. 


3.2.7. Handle Value List: HS_VLIST 


HS_VLIST is a pre-defined data type that allows a handle value to be 
used as a reference to a list of other handle values. An HS_VLIST 
value is a handle value whose <type> is HS_VLIST and whose <data> 
consists of a 4-byte unsigned integer followed by a list of 


references to other handle values. The integer specifies the number 
of references in the list. The references may refer to handle values 
under the same handle or handle values from any other handles. Each 


reference is encoded as an UTF8-string followed by a 4-byte unsigned 
integer that identifies the referenced handle and its value index. 


HS_VLIST values may be used to define administrator groups for 
handles. In this case, each reference in the HS_VLIST defines a 
member of the administrator group and the HS_VLIST value identifies 
the group as a whole. Client software must be careful, however, to 
avoid cyclic definition of value references. 


4. Handle System Service Model 


The Handle System is a distributed global name service. It consists 
of a single distributed Global Handle Registry (GHR) and unlimited 
number of Local Handle Services (LHS). These service components 
provide the name service (both resolution and administration) on 
behalf of Handle System client components. Handle System client 
components may also choose to use Handle System middle-ware 
components (e.g., the Handle System caching service) for efficiency. 
This section describes these components and their relationships to 
each other. 
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4.1. Handle System Service Components 


The Handle System defines a hierarchical service model. At the top 
level is the single distributed global handle service, also known as 
the Global Handle Registry (GHR). Underneath the GHR, there can be 
any number of Local Handle Services (LHSs). Each LHS must be 
registered with the GHR to manage handles under a distinct set of 
naming authorities. Naming authorities are managed by the GHR via 
naming authority handles (i.e., handles under the naming authority 
"Q.NA"). A naming authority handle can also be used to locate the 
service information (in terms of HS_SITE values) that describes the 
handle service responsible for handles under the naming authority. 
From the service information, clients can choose a service site and 
locate the responsible server for their handle requests. 


Handle System service components are scalable and extensible to 
accommodate any large amount of service load. A handle service, 
global or local, may consist of multiple service sites, replicating 
each other. Each service site may also consist of a cluster of 
computers working together to serve its respective namespace. Having 
multiple service sites avoids any single point of failure and allows 
load balancing among these service sites. Using multiple servers at 
any service site distributes the service load into multiple server 
processes and allows less powerful computers to be utilized for the 
name service. 


4.1.1. Global Handle Registry (GHR) 


The Global Handle Registry (GHR) is mainly used to manage naming 
authority handles and to provide service information for every naming 
authority under the Handle System. The GHR may also be used to 
manage and provide resolution and administration service to non- 
naming-authority handles. Unlike any LHS, which mostly manages 
handles under a few naming authorities, the GHR is primarily used to 
register naming authorities and provide service information for every 
LHS. In other words, the GHR is the single root service that 
registers every LHS and provides their service information via the 
use of naming authority handle(s). Every naming authority under the 
Handle System must be registered under the GHR as a naming authority 
handle. The naming authority handle provides the service information 
of the handle service that manages all the handles under the naming 
authority. The service information may be provided in terms of a set 
of HS_SITE values, or an HS_SERV value that refers to a service 
handle, as described earlier. 


The GHR may consist of multiple service sites, each described ina 


HS SITE value. These HS_SITE values are assigned to the designated 
naming authority handle "0.NA/0.NA", also called the root handle. The 
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root handle is the naming authority handle that maintains the service 
information for GHR. Top level naming authorities can only be 
created by administrators of the root handle. 


In order to communicate with the GHR, client software needs the GHR 
service information beforehand. The service information may be 
distributed initially with the client software, or obtained from some 
other secure sources (e.g., postal mail, secure web site, etc.). 
Client software may keep the service information to communicate with 
the GHR until the service information becomes expired (according to 
its TTL). The GHR must update its service information (assigned to 
the root handle) every time it changes its configuration. Client 
software with out-dated service information will be notified of the 
update every time it communicates with the GHR. The GHR must be 
maintained in such a way that any client software with out-dated GHR 
service information can still query the root handle for the latest 
update. 


Fig. 4.1.1 shows the GHR service information in terms of a set of 
HS_ SITE values. The GHR may consist of a number of service sites, 
each described in a HS_ SITE value. The figure shows a GHR service 
site located in US East Coast, as indicated in the <AttributeList>. 
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| | 
PublicKeyRecord: HS_DSAKEY, iQCuR2Rnw... 

| | | 

| ServiceInterface | | 

| || 

| 


| 
| | 
| <index>: 3 | | | 
| <type>: HS_SITE | | | 
| <data>: | | | 
| Version: 1 | | | 
ProtocolVersion: 2.1 | | 
| SerialNumber: 1 
| PrimaryMask: | | | 
| MultiPrimary: TRUE | | 
| PrimarySite: TRUE | | 
| HashOption: HASH_BY_HANDLE | | | 
| HashFilter: {empty UTF8-String} | | 
AttributeList: 1 | | 
| Description: Service site at US East Coast 
| NumOfServer: 3 | | | 
| th ah 
J 2 se ESS ee So aa eae =a e ae ae eee ee lied 
I te oar ae a ele Ona Aiea | | | | 
| ServerID: T | | | | 
| Address: :FFFF:132.151.2.150 | | | 
| Wa 
| bal 
| ServiceType: Resolution & Admin | | 
TransmissionProtocol: TCP & UDP | | 
| PortNumber: 2641 
Panna | | 
| Kae a 
| <TTL>: 24 hours | | 
| <permission>: PUBLIC_READ, ADMIN_WRITE A ina 
| <reference>: {empty} | |- 


Figure 4.1.1: GHR service information 


The GHR and its service information provide an entry point for any 
client software to communicate with the Handle System. For any given 
handle, client software can query the GHR for its naming authority 
handle. This will return the service information of the LHS that 
manages every handle under the naming authority. The service 
information will direct the client software to the handle server 
within the LHS that manages the handle. 
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4.1.2. Local Handle Service (LHS) 


A Local Handle Services (LHS) manages handles under given sets of 
naming authorities. Each naming authority defines a "local" 
namespace that consists of all of the handles under the naming 
authority. Note that a LHS is not a "local" service in terms of any 
network topology. It is called a "Local" Handle Service because it 
typically manages a restricted (local) namespace. 


A naming authority is "homed" at a LHS if all handles under the 
naming authority are managed by the LHS. A LHS may be home to 
multiple naming authorities. On the other hand, a naming authority 
may only be "homed" at one LHS. Note that a naming authority may 
also be homed at the GHR. 


| 
| | 
| <index>: 3 | | | 
| <type>: HS_SITE | | | 
| <data>: | | | 
Version: 1 | | 
| ProtocolVersion: 2.1 
| SerialNumber: 1 | | | 
| PrimaryMask: | | | 
| MultiPrimary: FALSE | | | 
| PrimarySite: TRUE | | 
HashOption: HASH_BY_LOCALNAME | | | 
| HashFilter: {empty UTF8-String} 
| AttributeList: 1 | | | 
| Description: Local Service for "10" | | 
| NumOfServer: 2 | | 
Pannen nnn anna naan | | 
| | ServerID: 1 | | | | 
| | Address: :FFFF:132.151.3.150 | | | | | 
| | PublicKeyRecord: HS_DSAKEY, iQCuR2R... | | | | | 
| | ServiceInteface: | | | | | 
| | ServiceType: Resolution & Admin || | | 
TransmissionProtocol: TCP & UDP | | | | 
| | PortNumber: 2641 f E 
| AREE ENEE eee Se TENEN ees ’ 
| <TTL>: 24 hours | | 
| <permission>: PUBLIC_READ, ADMIN_WRITE | |- 
| <reference>: {empty} |- 


Figure 4.1.2: LHS service information 
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Like the GHR, a LHS may also consist of many service sites with each 
site described by an HS_SITE value. The set of HS_SITE values for 
any LHS may be assigned to a service handle or to the relevant naming 


authority handle(s). Fig. 4.1.2 shows an example of HS_SITE values 
for a LHS. These HS _SITE values are assigned to the naming authority 
handle "0.NA/10". This suggests that the naming authority "10" is 


"homed" at the LHS specified in these HS_SITE values. Clients may 
query the GHR to obtain the service information in order to 
communicate with the LHS. Administrators of the naming authority 
handle are responsible for maintaining the service information and 
keeping it up to date. 


Note that a LHS may refer its clients to another LHS in response to a 
service request. This allows the LHS to further distribute its 
service in a hierarchical fashion. 


4.2. Handle System Middle-Ware Components 


Handle System middle-ware components currently include Handle System 
caching servers and Handle System proxy servers. These Handle System 
middle-ware components are clients to Handle System service 
components, but servers to Handle System client software. Handle 
System middle-ware components are used to provide additional 
interfaces to the basic handle service. For example, a Handle System 
caching server may be used to share resolution results within a local 
community. Additionally, a Handle System proxy server can be used to 
bypass any organizational firewall via HTTP tunneling. 


4.2.1. Handle System Caching Service 


Handle System caching service can be used to reduce the network 
traffic between Handle System clients and servers. Caching handle 
data, including the service information of any LHS, allows re-use of 
information obtained from earlier queries. 


Each handle value contains a <TTL> (Time to Live) field that tells a 
caching service how long the cached value may be regarded as valid. 
A zero-value TTL indicates that the value can only be used for the 
transaction in progress and should not be cached. A caching service 
may obtain its data directly from a handle service, or from another 
caching service that eventually gets its data from the handle 
service. 
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A caching service may be defined in terms of an HS_SITE value and may 
consist of multiple caching servers. For any given handle, clients 
can find the responsible caching server within the caching service by 
using the same hashing algorithm as used in locating the handle 
server within any handle service. 


Caching services are not part of any Handle System administration or 
authentication hierarchy. The Handle System protocol does not 
authenticate any response from a caching service. Clients are 
responsible to set up their trust relationship with the caching 
service that they select. They will also rely on the caching service 
to properly authenticate any response from any handle server. 


4.2.2. Handle System Proxy Server 


Handle System proxy servers can be used to enable handle resolution 
via other Internet protocols. For example, CNRI has built and made 
available a Handle System HTTP Proxy Server that will process any 
handle resolution in terms of HTTP protocol. The current DNS address 
for the proxy server is at "hdl.handle.net". The proxy server allows 
any handle to be resolved via a HTTP URL. The URL can be constructed 
as "http://hdl.handle.net/<handle>", where <handle> can be any handle 
from the Handle System. For example, the handle 
"nestrl.vatech_cs/tr—-93-35" can be resolved via the HTTP URL 
"http://hdl.handle.net/ncstrl.vatech_cs/tr-93-35" from any web 
browser. In this case, the URL is sent to the proxy server in terms 
of a HTTP request. The proxy server will query the Handle System for 
the handle data and return the results in terms of HTTP response. 


Using HTTP URLs allows handles to be resolved from standard web 
browsers without any additional client software. However, such 
reference to the handle also ties itself to the proxy server. If the 
proxy server changes its DNS name or otherwise becomes invalid, the 
reference (i.e., the HTTP URL) to the handle will break. Thus the 
selection or use of proxy server should be carefully evaluated. 


Proxy servers are not part of any Handle System administration or 
authentication hierarchy. The Handle System protocol does not 
authenticate any response from a proxy server. Clients are 
responsible to set up their trust relationship with the proxy server 
that they select. They will also rely on the proxy server to 
properly authenticate any response from any handle server. 


4.3. Handle System Client Components 
Handle System client components are client software that communicates 


with the Handle System service components. Client software may speak 
the Handle System protocol and send its request directly to a service 
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component. The response from the service component may be the final 
answer to the request, or a referral to another service component. 
The client software will have to follow the referral in order to 
complete the transaction. 


Client software may also be configured to tunnel its request via a 


middle-ware component. The middle-ware component will thus be 
responsible for obtaining the final result and returning it to the 
client. Unlike service components, middle-ware components will only 


return final results of client’s request. No service referral will 
be returned from middle-ware components. 


Various Handle System client components may be developed for various 
applications. The CNRI Handle System Resolver [17] is one such 
component. The resolver extends web browsers (e.g., Netscape or 
Microsoft Internet Explorer) in such a way that handles can be 
resolved directly in terms of "hdl:" Uniform Resource Identifiers 
(URIs). The Grail web browser [18], a freely downloadable software 
developed in Python [19], also supports the "hdl:" URI scheme and 
will resolve handles accordingly. For example, the handle 
"10.1045/july95-arms" may be resolved by entering its handle URI as 
"hd1:10.1045/july95-arms" into any of these resolver-enabled 
browsers. Details of the handle URI syntax will be specified ina 
separate document. 


5. Handle System Operation Model 


Handle System operations can be categorized into resolution and 
administration. Clients use the handle resolution service to query 
for any handle values. Handle administration allows clients to 
manage handles, including adding and deleting handles, and updating 
their values. It also deals with naming authority administration via 
naming authority handles. This section explains how various Handle 
System components work together to accomplish these service 
operations. 


Both resolution and administration may require authentication of the 
client. The authentication can be done via the Handle System 
authentication protocol described later in this section. Whether 
authentication is required or not depends on the kind of operation 
involved and the permissions assigned to the relevant handle value, 
and policies deployed by the relevant service components. 


The Handle System protocol specifies the syntax and semantics of each 
message exchanged between Handle System clients and its server 
components. This section provides a high level overview of the 
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protocol used to accomplish any service operation. The exact 
programmatic detail of each message (i.e., their byte layout or 
syntax) is specified in a separate document [8]. 


5.1. Handle System Service Request and Response 


The Handle System provides its service in response to client 
requests. A client may send a request to any handle server to 
provoke a response. The response either provides an answer to the 
request, or a status code with associated information that either 
refers the request to another service component, asks for client 
authentication, or signals some error status. 


Each handle under the Handle System is managed by its home service. 
The naming authority handle provides the service information (in 
terms of HS_SERV or HS_SITE values) of the handle service that 
manages all handles under the naming authority. Any handle request 
must be directed to the home service of the handle in question. 
Clients may find the home service by querying the corresponding 
naming authority handle against the GHR. Alternatively, this 
information may be found in a local cache or even be part of a local 


client configuration. Given the service information, clients may 
select a service site and locate the responsible handle server within 
the site. 


To resolve the handle "ncstrl.vatech_cs/te-93-35", for example, 
client software needs to know the home service for the naming 
authority "ncstrl.vatech_cs". The home service can be obtained by 
querying the naming authority handle "0.NA/ncstrl.vatech_cs" against 
the GHR. The GHR will return the service information in terms of the 
HS_ SITE values assigned to the naming authority handle. From the 
service information, clients can pick a service site, find the 
responsible handle server within the site, and send the resolution 
request to the handle server. 


Clients may require digital signatures from a handle server in order 
to authenticate any response from the server. The signature can be 
generated using the server’s private key. Clients may verify the 
signature using the public key available from the service information 
(refer to the <PublicKeyRecord> entry discussed in 3.2.2). 


A communication session may also be established between any client 
and handle server. Each session is identified by a unique session ID 
managed by the server. A session may be used to manage requests that 


require multiple interactions. It may also be used to share any TCP 
connection or authentication information among multiple service 
transactions. Each session may establish a session key and use it to 
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authenticate any message exchanged within the session. It may also 
be used to encrypt any message between the client and the server to 
achieve data confidentiality. 


The following diagram shows a handle resolution process in terms of 
messages exchanged between client software and Handle System service 
components. In this case, the client is trying to resolve the handle 
"ncestrl.vatech_cs/tr—-93-35". It assumes that the client has yet 
obtained the service information of the LHS "homed" by the naming 
authority "ncstrl.vatech.cs". The client has to get the service 
information from the naming authority handle managed by the GHR. The 
service information allows the client to locate the responsible LHS 
and query for the handle value. 


[HS Client]  ---~-------------3-7-----7----- > [Global Handle Registry] 
1. ask for the service 
information from the 
naming authority handle 
"Q.NA/ncstrl.vatech_cs" 


[HS’Claéenty) -<SSsaSsssssssssaStoHSss=ss5s= [Global Handle Registry] 
2. service information for 
the naming authority 
"nestrl.vatech_cs" 


[HS°“Clbent)! Sssseeseesssqcssocssaessseoss > [Local Handle Service] 
3. query the handle 
"nestrl.vatech_cs/tr-93-35" 
against the responsible 
handle server 


Vems 
(optional client authentication, depending on the service request) 
Nasera 
[HS Client]  <-------~-~--~------------------ [Local Handle Service] 
4. query result from the handle 
server + (optional) server 
signature 
Figure 5.1: Handle resolution example 
In Figure 5.1, the client is configured to communicate with the GHR 


for any handle service. In this case, the client first queries the 
GHR to find the home service for the handle’s naming authority. The 
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GHR returns the service information of the LHS that manages every 
handle under the naming authority. From the service information, the 
client can find the responsible handle server and query the server 
for the handle. The server may set up a session to authenticate the 
client if any of the handle value requires authentication. 

Otherwise, the server will simply return the handle value to the 
client. The server may send a digital signature as part of its 
response if required by the client. 


The above procedure assumes that the client software already has the 
GHR service information. That information was likely obtained from 
the client software distribution. The GHR will notify the client 
software if it learns that the service information used by the client 
software is out of date. Client software may retrieve the latest 
service information from the root handle "0.NA/0.NA". The root handle 
also maintains the public key that may be used to authenticate the 
service information. 


Note that a client may cache the service information of any naming 
authority so that subsequent queries for handles under the same 
naming authority may reuse the service information and bypass the 
first two steps shown in Figure 5.1. Client software may also be 
configured to query a caching or proxy server directly for any 
handle. In this case, the caching or proxy server will act as the 
[HS Client] in Figure 5.1 before returning the query result to the 
client. 


Client software under certain organization may also elect to bypass 
the GHR and communicate directly with a LHS managed by the 
organization. Doing so may achieve quicker response for handles 
managed under the LHS. The client software will be referred to the 
GHR for handles not managed by the LHS. 


5.2. Handle System Authentication Protocol 


The Handle System supports handle administration over the public 
Internet. Access controls can be defined on each handle value. The 
Handle System authentication protocol is the protocol used by any 
handle server to authenticate handle administrator upon any 
administration request. The authentication is also necessary when 
clients query for handle values that are read-only by the handle 
administrator. Handle administration include adding, deleting or 
modifying handle values, and adding or deleting handles. Naming 
authority administrations are carried out as handle administrations 
over the corresponding naming authority handles. 
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The Handle System authentication protocol does not perform any server 
authentication. However, a client may authenticate any server 
response by asking the server to sign its response with digital 
signature. 


By default, the Handle System authenticates clients via a challenge- 
response protocol. That is, after receiving a client’s request, the 
server issues a challenge to the client if authentication is 
necessary. To be authenticated as the administrator, the client has 
to return a challenge-response, a message that demonstrates 
procession of the administrator’s secret. The secret may be the 
private key or the secret key of the administrator. This challenge- 
response allows the server to authenticate the client as the handle 
administrator. Upon successful authentication, the server will 
fulfill the client’s request if the administrator is given sufficient 
permission. 


For example, suppose a client sends a request to the handle server to 
add a new handle value. The server will issue a challenge to the 
client in order to authenticate the client as one of the handle 
administrators. If the client possesses the private key of the 
administrator, she can use it to sign the server’s challenge and 
return the signature as part of her challenge-response. The server 
will validate the signature in order to authenticate the client. The 
client will be notified if the validation fails. Otherwise, the 
server will further check if the administrator has the permission to 
add the handle value. If so, the server will add the handle value 
and report success to the client. Otherwise, a permission-denied 
message will be returned. 
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The following diagram shows a typical authentication process in terms 
of the messages exchanged between the client and the handle server. 


i a n > [Handle Server] 
1. client request 
+ (optional) client credential 


pCltenti: “<=. Sasha SoS Sa ees a= [Handle Server] 
2. server’s challenge to client 
+ (i.e., nonce + MD5 of client request) 


[ClTent |" - HeasseosS essa e > [Handle Server] 
3. reference to handle administrator 
+ challenge-response from client 


[Client] “< -sSsaqssSoSSaasaesr sansa esaaoe [Handle Server] 
4. server acknowledgement 


Figure 5.2: Handle System authentication process 


In Figure 5.2, the client sends an administration request to the 
handle server (along with optional credential discussed later). The 
server decides that client authentication is required and issues a 
challenge to the client. The client identifies itself as a handle 
administrator and returns the challenge-response to the server. The 
server authenticates the client as the administrator based on the 
challenge-response. It also checks to see if the administrator is 
authorized for the administration request. If so, the server will 
fulfill the request and acknowledge the client. 


Handle servers must authenticate the client before fulfilling any 


request that requires administrator privilege. The exact 
authentication process varies depending on whether public key or 
secret key is used by the administrator. It also depends on whether 


the handle used to store the administrator’s key is managed by the 
same handle server or not. 


When public key is used, the challenge-response from the client 


contains its digital signature over the server’s challenge. The 
server can authenticate the client by verifying the digital signature 
based on the administrator’s public key. If secret key is used, the 


challenge-response from the client carries the Message Authenticate 
Code (MAC) generated using the secret key. The server may 
authenticate the client by generating the same MAC using the 
administrator’s secret key and comparing it against the challenge- 
response. 
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The reference to handle administrator in Fig 5.2 is also calleda 
key-reference. It refers to a handle value that contains the key 
used by the administrator. If the key-reference is managed by the 
same handle server (e.g., a handle value assigned to the same 
handle), the server may use the key directly to do the 
authentication. If the key-reference is managed by some other handle 
server (whether or not within the same handle service), the server 
will have to send a verification-request to this other handle server, 
call it the key-server, in order to authenticate the client. The 
verification-request to the key-server carries both the server’s 
challenge and the client’s challenge-response. The key-server will 
return a verification-response, signed using the key-server’s private 
key. The content of the verification-response will depend on the 
handle value referenced by the key-reference. If the key-reference 
refers to a public key used by the administrator, the verification- 
response will contain the public key of the administrator. 

Otherwise, the key-server will verify the challenge-response on 
behalf of the requesting server and return the result in the 
verification-response. The following diagram shows the control flow 
of the authentication process where the key-reference refers to a 
handle value that contains the administrator’s public (or secret) key 
and the key-server is some other handle server. 
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1. client request. 


| | | | 

A eas aa a | 

| | 2. session ID | | 

| | + server’s challenge | 

| Handle | <------------------------------- | Handle | 

| System | | server | 

| client | 3. session ID | receiving | 

+ response to the challenge client 
| | + administrator reference | request | 
a a en ee ey eT a ee ee ene pe ee yee ee, > 

| | | | 

| | 6 server acknowledgement | 

| | Baar eas Rae ten aso Sr een eer | | 
| oe 

4. Verification | | 5. verifi- 
request | | cation 

| | response 
| | (signed) 
v | 


| The handle server (the | 
| key-server) that manages | 
| the key referenced by | 
| the key-reference | 


Figure 5.3: Authentication process requiring verification 
from a second handle server 


Secret key based authentication via a second handle server, i.e., the 
key server, provides a convenient way to share a common secret key 
(e.g., pass phrase) among handles managed by different handle 
servers. However, it should not be used to manage highly sensitive 
handles or handle data. The authentication process itself is 
expensive and relies on a third party, i.e., the key-server, for 
proper operation. Additionally, the secret key itself is subject to 
dictionary attack since the key-server cannot determine whether the 
verification-request comes from a legitimate handle server. A handle 
service may set its local policy so that secret key based 
authentication can only be carried out if the handle server 
(receiving the client request) is also the key-server. 
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Local handle services may define additional local policies for 
authentication and/or authorization. Handle System service 
components may also choose to use other Internet authentication 
mechanisms such as Kerberos [20] or some Transport Layer Security 


protocol [21]. Details of these will be addressed in a separate 
document. 
6. Security Considerations 


Handle System security considerations are discussed in the "Handle 
System Overview" [1] and that discussion applies equally to this 
document. 


The Handle System delegates handle administration to each handle 
administrator who may or may not be the server administrator. Handle 
administrators are allowed to choose their own public/secret keys 
used for authentication. The security of Handle System 
authentication depends on the proper key selection and its 
maintenance by the handle administrator. Handle administrators must 
choose and protect their authentication keys carefully in order to 
protect the handle data. Handle server implementations may deploy 
policies that regulate the selection of public/secret keys used for 
authentication. For example, a handle server may require that any 
authentication key must be no less than certain number of bits. It 
may also prohibit the use of secret keys because of the potential 
dictionary attack. 


The Handle System data model supports execution permission 
(PUBLIC_EXECUTE, ADMIN_EXECUTE) for each handle value. While this 
allows better sharing of network resources, it also raises many 
security considerations. Execution privilege should be restricted 
within the permissions of certain user account (corresponding to the 
handle administrator) on the server to prevent system-wide 
disruption. Switching between computing platforms for the server 
should also be careful to avoid any unexpected behavior. 
Implementations may choose not to support the execution permission, 
or provide options so that it can be disabled. 


To protect against any irresponsible use of system resource, handle 
servers may implement quota control. The quota control can be used 
to put limits on the number of handles under a naming authority, the 
number of handle values allowed for any given handle, the maximum 
size of any handle value, and the number of sub-naming authorities 
under a naming authority. Handle servers must report error if the 
result of a handle administration violates any of these limits. 
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